A Netqueue feature in a hypervisor provides different algorithms to effectively utilize physical network interface card (NIC)'s receive (Rx) queues. Physical MC provides Rx queue features such as receive side scaling (RSS), large receive offload (LRO), latency-sensitive, and Netqueue encapsulates these queue capabilities and makes best attempt to distribute Rx-filters of the clients such as virtual NIC and VM kernel NIC on these Rx queues, activating only required number of Rx queues with required queue feature. In turn, physical NIC tries to match incoming packet against applied Rx-filters. Further processing of that packet is done at the central processing unit (CPU) associated with corresponding Rx-queue. Thus, processing is scaled to multiple CPUs. Netqueue algorithms are based on load calculation. They calculate the load of the filters (based on its transmit (Tx), Rx packet rate), and assign them a Rx queue.
Rx queues are of two types. For the first type, a driver exposes a single Rx queue to a networking stack of a hypervisor. The Rx queue is mapped to single hardware Rx queue, and it accepts Rx-filters (such as MAC based filters or combination of outer, inner MAC). If the incoming packets matches any of those applied filters, then further packet processing is done on that Rx queue. Netqueue layer present in a hypervisor could allocate such Rx queues with additional features like LRO and latency sensitive. Another type is where a driver exposes a single Rx queue with Receive Side Scaling (RSS) feature, which is backed by multiple hardware queues. This pool of queues backing up the single Rx queue with a RSS feature is referred to as RSS engine or RSS pool. Netqueue layer in a hypervisor allocates such Rx queue with RSS feature and applies filter on them. If the incoming packets matches any of those applied filters, then one more level of queue-selection is done. This selection process is done by executing RSS hash algorithm supported by the hardware (such as Toeplitz hash function) on selected fields of the packet. Output of this function is a hash-value that is used as selection criterion to decide the hardware queue in the pool to process this packet. Some devices further provide indirection table that is mapped with different queues for different hash values. Hardware will execute the packet with particular hash value on the queue mentioned in the table.
Currently, physical NICs expose a single RSS queue to the operating system which represents a pool of hardware queues (number of hardware queues typically ranges from 8-16). And, in a hypervisor one may apply filters belonging to virtual kernel network interface cards (management, infrastructure traffic (NFS, vMotion, vSAN, VTEP)) to this RSS queue. Also end user can anticipate some of service VMs (such as Edge Service Gateway in NSX) as high t-put VM and statically request for RSS queue for them.